Over the last nine years, many engineering organizations and countless systems practitioners have invested significant time and energy into the transition from document-centric to model-centric systems engineering. During this time, we have made notable progress. Unfortunately, we have also contributed to – if not created – several myths and misconceptions which serve neither the transition nor the greater practice of systems engineering.
Myth #1: Models are new
In the classic INCOSE graphic depicting the transformation to model-based systems engineering (MBSE), documents are shown on the left, models on the right, and the benefits of the transformation in the middle. The implied (and often stated) message has been that models are new to systems engineering. Nothing could be further from the truth.
Models have always been part of systems engineering. In fact, models are core to the way engineers think and work. The difference is one of focus and treatment. Under a document-centric paradigm, models are secondary, supporting, and descriptive. They may be represented by Excel spreadsheets, sketches on a legal pad, or encoded in high fidelity analytical tools. More often than not, the model resides only in the mind of the systems engineer.
The transition to models represents a change in centricity – one in which implicit models are made explicit, secondary models becomes primary, and descriptive models are now required. In doing so, we gain clarity and power – in analysis, in communication, in alignment and shared understanding. In doing so, we move from low fidelity representations of the model to a high fidelity model (or, more specifically, connected models) capable of serving as the “single source of truth.”
Myth #2: Documents are disappearing
Those hoping to see the end specifications and other documents in systems engineering will not get their wish anytime soon (if ever). If MBSE is about a change in centricity where models move from secondary position to the primary position, it’s also about moving documents from the forefront to a supporting role. Documents as the primary specification are fundamentally flawed. When used in a supporting manner, they are priceless.
The flaw in engineering via document is multi-fold. The written word is a relatively low fidelity representation of the design concept and specification present in the engineer’s mind. Far worse than the content loss in moving from the engineer’s mind to the written word is the loss and distortion inevitably introduced when reading a document and constructing your own mental model of what it represents. If the author and the reader have a shared context and shared framework, this translation from mental model (the author’s) to the written word to mental model (the reader’s) may be largely successful. More often than not, this translation is marked by loss of information and introduction of defects, much the same as the children’s game of “telephone” where a simple message is whispered from child to child around a circle with the final pronouncement bearing only a vague resemblance to the first message.
So if all this is true, why should we keep documents? While converting from a mental model to and from the written word is inherently risky, documents are powerful mechanisms for communicating with a diverse community. When you consider that systems engineers must communicate effectively with the customer, stakeholders, users, management, other systems engineers, software engineers, and subject matter experts, it is clear that this diverse group will never share a common technical language or notation. Documents certainly have a role to play.
The transition is simply that documents move from the primary role of specification to the secondary role of communication. Key in this transition, documents must be generated directly from the model (effectively serving as a simple or complex query and representation of the model). This ensures that the model is the single source of truth and the document production process – though a reduction in fidelity – cannot introduce defects.
Myth #3: There is one kind of model
In 2014, I had the pleasure of attending a CIMdata event on MBSE and delivering an INCOSE perspective. As I listened to the other speakers, I heard fascinating descriptions of high fidelity physics-based models, quite appropriate given CIMdata’s PLM focus. While I appreciated the presentations, they bore little resemblance to the MBSE conversations dominated by architectural dimensions highlighted in traditional systems engineering forums. Which is right? Which is the true systems model? The answer is that both are.
There are two primary classes of system models. There is the architecture model key for innovation, resilience, and grappling with complexity. There are also the analytical models (often, but not always, physics-based) representing the key systems relationships critical for rigor, effectiveness, and efficiency. Depending upon the type of system, the purpose of the systems engineering effort, and several other factors, the emphasis may fall on either the architectural side or the analytical side, but both are valuable.
In recognizing these classes of model, we must recognize – and make explicit – the interrelationships between them. There is currently no one grand unified model for systems engineering, and I doubt I will see one in my lifetime. Instead, we must focus on making the implicit semantic relationships between the various detailed analytical models and the higher-level architectural model explicit. To borrow from middle earth, though there may not be ‘one model to rule them all’, the architectural model with the appropriate semantic connections is the ‘one model to coordinate them all.’
Myth #4: SysML equals MBSE
Models are not new, and neither is MSBE. The roots and practice (along with corresponding tools and methodology) trace back to at least 1968 and TRW’s work with the U.S. Army on ballistic missile defense. The recent focus on MBSE traces to the rise of software-intensive systems in the 1990s and the corresponding effort to close the gap between systems and software engineers. That effort gave rise to SysML, a profile of UML, in the belief that a shared notation could improve the situation. Unfortunately, it also gave rise to the misconception that SysML is MBSE.
SysML is a highly valuable set of graphical representations, one intended to improve systems engineering communications in a model-based environment. However, it is neither a model nor a language. Instead, it is a series of diagrams – each underpinned by a separate specification – designed for the capture and communication of system design. It is not the only valid representation set nor the only representation of value. Documents, tables, and more traditional diagrams (function flow block diagrams, physical block diagrams, hierarchy diagrams, and more) are all valid and valuable representations of system architectural models.
The key – as with all communication and analysis – is to tailor the representation to the audience (what are they comfortable with and what do they need to see) and to the key viewpoint of interest. Done well, a diverse set of textual and graphical views represent a rich toolbox through which to construct, analyze, and communicate a common model from varied contexts and viewpoints. Done poorly, the diagrams become disjoint pictures, leading the team into the trap of diagram-based engineering (and creating myth 4.a “I am drawing diagrams, so I must be doing MBSE”).
The transformation of systems engineering practice from document-centric to model-centric is key to addressing 21st century challenges. It advances our methods and tools for systems engineering, and more importantly, enables model-based engineering which promises radical improvements in quality and time-to-market while simultaneously reducing lifecycle cost. While this transformation has traditionally been framed as revolutionary, we better serve ourselves and the transition if we properly see it as evolutionary while avoiding the pitfalls of the myths and misconceptions which accompany the change.
